-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
install: Add support for pulling LBIs during install #860
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
a6374a6
to
fb80b8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good to me!
I guess the last step is probably a test? This one should also be pretty easy to do with our existing "install inside GHA runner" case where we just verify that the LBI isn't pulled right?
BTW will trade my review for a review here |
fbaa5b0
to
f450bbf
Compare
Yep, once you've reviewed the new interface I'll add a test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interface LGTM!
Needs a |
This one just needs a test right? |
Yep |
Coming again to this, I'm not so sure I understand what you meant. The GHA integration tests make use of a Containerfile ( I thought instead we could test it by simply dogfooding in the existing logically bound install tmt plan, i.e.: diff --git a/xtask/src/xtask.rs b/xtask/src/xtask.rs
index 7257511..f069935 100644
--- a/xtask/src/xtask.rs
+++ b/xtask/src/xtask.rs
@@ -11,11 +11,6 @@ use fn_error_context::context;
use xshell::{cmd, Shell};
const NAME: &str = "bootc";
-const TEST_IMAGES: &[&str] = &[
- "quay.io/curl/curl-base:latest",
- "quay.io/curl/curl:latest",
- "registry.access.redhat.com/ubi9/podman:latest",
-];
fn main() {
if let Err(e) = try_main() {
@@ -202,9 +197,6 @@ fn test_tmt(sh: &Shell) -> Result<()> {
cmd!(sh, "cargo run -p tests-integration run-vm prepare-tmt").run()?;
- // pull some small images that are used for LBI installation tests
- cmd!(sh, "podman pull {TEST_IMAGES...}").run()?;
-
for (_prio, name) in tests {
// cc https://pagure.io/testcloud/pull-request/174
cmd!(sh, "rm -vf /var/tmp/tmt/testcloud/images/disk.qcow2").run()?; Then *While writing this comment, I started digging into what it would take:
Quite a rabbit hole... I knew nothing about all this osbuild stuff or how bib only recently started using Anyway so to get osbuild to Or I could test this some way that's not dogfooding |
Yeah... One angle in this for me is that there's too many installers and I'm trying hard to centralize things in a very opinionated Basically 95% of "files" on the system for the base OS should be owned by bootc because it's also the thing responsible for updating them.
This is a complex topic. I don't think we need to plumb through What we don't have right now is install tests that run through TMT. We probably should - we could do this via an "alongside" install for a package-based cloud image or so. Though we still have this overall issue in getting the container image into the VM in scenarios like that...which is the same thing needed for virt-manager/virt-manager#739 (basically allow the VM to fetch the container via virtiofs or so from the host). Currently though we do have a suite of install tests that basically mutate a GHA runner, that's what this guy is: bootc/.github/workflows/ci.yml Line 87 in c4f3e33
The advantage of this test is in CI it's cheap and reliable, but the downside is we can't actually reboot after install, and we don't have a single handy script to spawn a temporary VM to run them. So...what we could do in that suite is add a container build that does use LBIs in that path (sharing with the existing TMT test). |
The bootc plugin should enable these. We already have one tmt based install test here. Seems like the issue here is with propagating install flags through the plugin. I think this would be pretty straightforward if the tmt plugin switches to calling bootc to do the install instead of image builder. Then the tmt plugin could add a field to define arbitrary bootc install flags. The only reason I chose to use image builder in the tmt plugin is because that's what the customer docs tend to tell users to do. |
Those tests are good but I think we are talking about something different here. Remember that in the primary initial target for the That testing flow could actually look closer to what we're doing in the GHA flow I linked above, just pretending that the image we built there is actually fetched from a registry i.e. we do But in the short term I think what we could do with the TMT tests is spawn a non-bootc VM and test via Or of course, we could try standing up a CI path that injects bootc-under-test into an Anaconda ISO because that's our target for this for real. |
Writing down what was discussed in real time. I think there will still be value in testing this in the containerized install path via the existing tmt framework. For the bootc install outside of container path, we could add another option to the bootc tmt plugin to enable this. Something like |
I rebased this on main, OK if I push it?
|
Partially solves containers#846 This adds a new `--bound-images` option to `bootc install` which will allow the user to choose how they want to handle the retrieval of LBIs into the target's container storage. The existing behavior, which will stay the default, is `--bound-images stored` which will resolve the LBIs and verify they exist in the source's container storage before copying them into the target's container storage. The new behavior is `--bound-images pull` which will skip the resolution step and directly pull the LBIs into the target's container storage. The older `--skip-bound-images` option (previously hidden) is now removed and replaced with the new (but still hidden) `--bound-images skip` option. Signed-off-by: Omer Tuchfeld <[email protected]> Signed-off-by: Colin Walters <[email protected]>
install: Add support for pulling LBIs during install
Partially solves #846
This adds a new
--bound-images
option tobootc install
which will allow the user to choose how they want to handle the retrieval of LBIs into the target's container storage.The existing behavior, which will stay the default, is
--bound-images stored
which will resolve the LBIs and verify they exist in the source's container storage before copying them into the target's container storage.The new behavior is
--bound-images pull
which will skip the resolution step and directly pull the LBIs into the target's container storage.The older
--skip-bound-images
option (previously hidden) is now removed and replaced with the new (but still hidden)--bound-images skip
option.